>Second question: How can I write a program that keeps the LD_LIBRARY_PATH >variable from being exploited? i.e. the SUN 'login' bug where LD_LIBRARY_PATH >got exploited. I would ASSUME I could prevent this by doing something like: >putenv("LD_LIBRARY_PATH"), but that just seems too simple to be a true fix. >(If it's not complex, it's not right? :) Don't assume that LD_LIBRAY_PATH is the only variable you have to worry about. I was able to easily break "sudo" with the LD_PRELOAD variable (we've since fixed it by supplying a brand new environment, instead of re-using the old one). A strings on /usr/lib/ld.so, show the following items which are most likley environment variables: LD_LIBRARY_PATH LD_TRACE_LOADED_OBJECTS LD_PROFILE LD_PRELOAD LD_SYMBOLS_PUBLIC Of course only LD_LIBRARY_PATH seems to be documented in the man pages. Maybe someone from Sun can comment on what the rest of these do (please?) >From experimentation, the LD_PRELOAD variable should point to a library (not a directory of libraries). That library will be loaded before the standard library path (or LD_LIBRARY_PATH) is searched.